XJ Key Approaches 


1. Pervasive use of safe (& analyzable) programming languages 
= type safety and memory safety 
- including device drivers, OS components, applications 
2. Improve system resilience despite software errors 
- failure boundaries between components 
- improve extension model 
- explicit error notification. 
3. Increased verification 
- specification at multiple levels of abstraction 
- closed environments with explicit cross-domain interfaces. 
- design for verifiability 


channels, 


Closed Kernel 
~ 95% writen in C= 
* 17% of fles contain unsafe Ce 
1 5% of les contain x86 or C++ 
- OS services В drivers in processes 
Software isolated processes. 
(SIPs) 
Some unsafe code in trusted runtime 
processes closed at start time 
Safe and efficient communication 
via strong interfaces 
channels between processes 
С channel behavior is specified а checked 
- checked behavior enables efficient 
ped 
Type safety is crux of verification 
& protection 


Challenge 1: 


Pervasive Safe Languages 


* Started with C# 
- actually Spec# (= C& + pre/post-conditions and invariants) 
- processes can be written in any safe language (with MSIL 
compiler) 
* Added features to C# for systems programming 
= increase programmer control over allocation, initialization, and 
memory layout 
* Explore language features to support programming and 
verification 
- message passing communication 
= factoring libraries 
- compile-time reflection 


Performance of Safe 


Languages 


* Diverse requirements (not just speed) 
= execution time, memory footprint, pause times, expressibility 
* device drivers should have «100 KB dynamic footprint 
* kernel shouldn't fall due to transient memory exhaustion. 
* able to write wide range of applications and devices 


+ JVM & CLR's design points not always appropriate 

- monolithic runtimes ("one size fits all”) 

+ powerful, general-purpose environments 

* large memory footprints (~4 MB per process for CLR) 

* long ist of dependencies (CLR PAL requires >300 Win32 APIs) 
= JIT compilation 

+ introduces complexity, performance overheads 
- runtimes replicate OS features 

+ security, threading, configuration, etc 


Small, Customizable, 


Safe Environment 


* Singularity modular execution environment 
= runtime, garbage collector, and library selectable on per- process basis 
* reduce runtime overhead 
+ enforce design discipline and system policies 
- lightweight, subsetable runtime 
- language support for factoring runtime and libraries 
- compiler support for specializing runtime and libraries 
+ remove code for unused/disabled language features. 
• Ahead-of-time optimizing compilation (MSR Bartok) 


+ Merge OS & language run time 
= integrate partially redundant features into OS 
= no separate JVM or CLR 


> > v Runtime Overhead 


C - static lib 


Ct - w/ GC 


C++ - static lib | 
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C process w/ GC has similar memory footprint to C++ 
- minimal process (no GC or exceptions) is ~16K 


Challenge 2: 


Run-Time Resilience 


* Software errors should not cause system failure 


* Resilient system architecture 
- isolate system components to prevent data corruption 
- provide clear failure notification 
= implement policy for restarting failed component 


"à Extensibility Through 


Dynamic Code Loading 


+ Code loading is common extensibility mechanism 
= DLLs, Java class loading, browser plug-ins, Eclipse, 
• Shared state reduces dependability 
= 85% of Windows crashes are device drivers 
* problem at al levels, not just the OS 
^ по isolation boundary between code and extension. 


• Singularity processes are fundamental unit of failure isolation 


= по dynamic code loading or run-time code generation 
+ al code present when process starts execution 


= any extension executes in separate process 
* wo closed environments with well-defined interface 


- no shared memory 


Making Processes 


Lightweight 


• Hardware context switch mechanisms can be expensive. 
= use of kernel calls, IPC hited by their cost 


+ Software Isolated processes (SIPs) 
= processes execute only safe or trusted code 
- process is exclusively owner of a set of pages 
- protection and isolation enforced by language safety and kernel ABI design (not hardware) 
= global invariants: 


+ Closed object space (not address space) 


Fast Interprocess 


Communication 


Channels 
= bi-directional, asynchronous IPC mechanism between two processes 
- contract specifies messages and communication protocol 


+ "Send & forget" message semantics 
- eh message and endpoint owned by at most one process 
= ownership transferred at send 

Correct usage statically enforced 


Efficient implementation 


"= — i 


y Failure Isolation 


+ SIPs are failure containers 
= no shared implementation ог state across SIPs 
- process runtimes are distinct 


* On SIP failure: 
- clean failure notification on peer channel endpoints 
- resources reclaimed by OS 

* Recovery feasible, not automatic or transparent 
= peers can recover and continue 
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create & start 


+ Why? 


= all SIPs run in ring O 
- static verification replaces hardware protection 
= good optimizing compiler (not JIT) 
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сһайепде 3: 


More Verification 


* Integrate specifications throughout system 
- language 
- interprocess communication 
- application & device driver descriptions 


* Detect errors early, verify code late 
- language safety essential to system integrity 


ТЕ 


connected: 
САМАСА Вори? -> port! -> connected: 
HT -> тесей уоту, 
Miner поеми: 
ET 


Example: 


Contract 
public contract Tepconnectioncontract “ 


State connected ; one ( 


БЕИ нет => port! => conce 


bonesending? -> neceiveonty: 
kee n МУ: 

7 472 
ret 2 Ser 


Client 


ann sendnead() 
Switch receive ( 
‘case conn.cata(readoata) 
‘aneatuter.adsTeTatI(readoata); 
return true: 


. 
‘return fils 


Example: 


Applications Specifications 


* Application is first-class abstraction with 
identity 
- code + resources + manifest 


* Manifest specifies 
- software components 
- dependencies 
- exported channels 
- hardware or software resource requirements 


Device Driver 


Specification erry 
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Specification Used 
Many Ways 


Specification Used 
Many Ways 


Driver 
Manifest 1. Load driver E 
Conflict 
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Specification Used 
Many Ways 


Driver 
Manifest 1. Load driver 


2. Allocate 
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3. Create 
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sis T =] 
Manifest [лт ] 
| e 


cation 


Verification ensures 


- never install an program that will break 
another program 


- never start a program without appropriate 
resources 


- never grant a program access to undeclared 
resources 


* All of these checks performed statically 


* Singularity is basis for more dependable systems 
- pervasive use of safe programming languages 
- lightweight, closed, customizable run-time environment 
- verifiable specification of system behavior 


* Working research prototype 
= driving research in large number of areas 


* More information: 
— 


MSR Tech Report MSR-TR-2005-135 


